ARM/RISC OS MAME, version 0.34 beta 5.2, ported by Gareth S. Long ================================================================= Last updated: (26 Oct 1998) ** PLEASE READ THE CHANGELOG AT THE BOTTOM OF THIS FILE FOR IMPORTANT UPGRADE INFORMATION, ESPECIALLY IF YOU ARE NOTICING DIFFERENCES BETWEEN THE CURRENT MAME AND YOUR LAST VERSION ** ** PLEASE ALSO READ THE ACCOMPANYING README.TXT AND WHATSNEW.TXT RELATING TO MAME, ESPECIALLY THE BITS AT THE TOP IN CAPITAL LETTERS, IN MUCH THE SAME WAY AS YOU ARE READING THIS NOW ** AND READ THEM EVERY TIME THIS FILE IS UPDATED. *** PLEASE, PLEASE, PLEASE MAKE SURE YOU ACTUALLY DID THE ABOVE *** ... I'LL BE ABLE TO TELL... One more note: People doing magazine articles and things; please let me know in advance! Publishers lead times mean you're probably writing a retro retro into the world of retro gaming by the magazine hits the subscribers even. I can give accurate information on events to coincide correctly with publication dates. What is it? =========== Welcome to ARM MAME, the Multiple Arcade Machine Emulator. MAME is a large modular emulation system which allows a relatively huge number of classic arcade machine PROM images spanning several different games motherboard and chipset types to be emulated and run successfully. The upshot is that you get the chance to run original Arcade games *exactly* as they were; you *are* playing the coin-op version, and no substitute. As a result, and rightly so, MAME has generated a huge worldwide following, spawning tens of dedicated web pages with hundreds of links relating to various aspects of MAME, from ROM image addresses and screenshots, to technical information, to reminiscences from people who mis-spent almost their entire youth and some way beyond in a dingy chipshop playing pacman, or who were beaten to within an inch of their lives by an angry cafe owner for breaking a Robotron 2084 joystick, or something. MAME is the largest emulation project currently in existence, many people having contributed drivers, information, etc, towards it's development. MAME is, as a result, constantly in a fluid state, usually undergoing 3-4 revisions a month, each revision usually adding an average of 25 games to the 'supported' list. This has changed a little recently, with a drive towards higher initial game emulation quality. This now means that newer MAMEs are released every 2-3 months, however, the nnumber of new games supported per release now stands at around 150! Typically, two new game drivers are added to MAME a day. This port is intended to provide all the functionality of MAME for RISC OS. Where applicable, each of the features available to, say, MS DOS is available for the RISC OS port too. It's also a bit good. The documentation for MAME should have arrived within this archive (as well as a copy of the distribution license) - the MAME documentation is fairly generic but has some DOS specific stuff towards the end. The RISC OS setup instructions are given below. What do I need? =============== Best results are obtained with a StrongARM based Risc PC. Sorry, but versions of MAME for other machines are only really usable on a 486DX100 or similarly specced machine, or above for some games. Having said that, ARM 710 users shouldn't have much of a problem with most games. I am committed to making MAME more usable on lower-ended machines. Honestly: MAME will work on older machines, but the palette will be completely wrong at the moment for reasons I will describe below. Expect this to change soon, however. Picking up the game PROMs ========================= These are fairly widely available via the internet. In order to use the games legally, you should in theory own the original game machine boards (I do for many of them, yes really :-) ) and you shouldn't just go picking them up via sites like http://www.davesclassics.com .. so I'm sure you won't. Organising MAME =============== This will change a great deal as frontends for MAME are developed and put into play, and als0o as MAME itself evolves.. Create a directory called MAME somewhere on your hard disc. I *strongly* recommend that this directory be an image filing system archive (zipfile or TBAFS archive will do nicely, as will a DOSFS partition.. public domain utilities like X files etc also work well. You can even use StrongHelp to archive the files inside a new StrongHelp manual). This allows you to use more than 77 filenames in a directory, and also allows you to use filenames greater than 10 characters, which some games need) Unpack the contents of the MAME archive into it. Create two blank directories, called 'CFG' and 'HI', alongside the MAME executable. Unpack any games you have downloaded into directory names which match the game name (like 'pacman','dkong' etc). These should be subdirectories within your MAME directory. Your resulting directorystructure should look thus (names in square brackets are directory names): [MAME] (image filing system archive) \ \ MAME (executable) MameVox2 EmUtils [ROMS] [CFG] [HI] [... etc] | /--------------\ [pacman] [invaders] | | | pacman/a invaders.e ... pacman/b invaders.h ... pacman/c invaders.g ... ... ... ... To run MAME, set your current directory to that of the MAME image filing system ardchive (double clicking on the provided SetDir obeyfile will do this for you). Note that as of MAME 0.30.1, front ends/you are able to change the directory paths. As a result, you can also use a RISC OS search path, enabling ROM sets to exist in multiple directories, which gets round the problem of otherwise having a limitation on the number of ROM directories you can have if you don't use an image filing system like SparkFS. Furthermore, MAME 0.31 and above have direct zipfile support built in, meaning you can download a zipfile from the net, and it will treat this as a directory regardless of whether you have SparkFS loaded or not. In this case, SparkFS will be used if the file is stamped to 'DDC' or a directory image, if it is typed as 'data', the internal Zip routines will be used. If you want sound, double-click on the SetVox obeyfile. Ensure you have a large wimpslot set - drag the next slot so that it's at least 6 Megabytes - many games supported now need over 10 MBytess to run. Other games will need more. Press f12, then type 'mame ' (eg 'mame dkong', 'mame zaxxon' etc) Some generic keys are: 3 Insert coin (pulse to coin mech 1, more specifically) 1 Start 1 player game 2 Start 2 players game Tab Enter dip switch, key and joy settings, and credits display menu Pressing TAB again returns you to the emulator, ESC will exit from MAME. P Pause F3 Reset F4 Show the game graphics. Use cursor keys to change set/color, F4 to exit F8 Change frame skip on the fly (60, 30, 20, or 15) F9 To change volume percentage thru 100,75,50,25,0. Keypad PLUS and MINUS change the volume with fine granularity F10 Toggle speed throttling F11 Toggle fps counter F12 Save a screen snapshot numpad +/- Volume adjust left shift + numpad +/- Gamma correction adjust ESC Exit emulator Note that running mame with the '-cheat' option allows you to use the fairly extensive cheat facilities available. Remember that with MAME 0.28 and below, dip switch/key settings are *saved* in the game directory as a */DSW and *.key (etc) files (MAME 0.25 groups it all into a /CFG file)... You can remove these to reset to the defaults. Some upgrades to MAME (particularly those up to 0.25) will necessitate the manual removal of these files. Note that the generic ReadMe file always warns you to do this. Warnings in this file will almost always also apply to the RISC OS version. MAME 0.29 and above store the CFG and HI files in their own directory, alongside, but separate from the games directories, see the hierarchy chart for where to put these two blank directories - they will become filled as you play more games. Have fun. Other options ============= MAME takes a veriety of options other than just the game name. All the generic MAME options are supported, all the applicable DOS options are supported, and there are a few RISC OS specific ones. These are as follows. -320 tell MAME to use a vesa 320x240 video mode -320x256 same as above, video mode is 320x256 -512 same as above, video mode is 512x384 -640 same as above, video mode is 640x480 -800 same as above, video mode is 800x600 -1024 same as above, video mode is 1024x768 -1280 same as above, video mode is 1280x1024 -1600 same as above, video mode is 1600x1200 -XxY where X and Y are width and height (ex: 800x600) (not yet implemented) -vsync synchronise video display with the video beam instead of using the timer. This works best with -noscanlines and the -vesaxxx modes. Use F11 to check your actual frame rate - it should be around 60. If it is lower, try to increase it with -vgafreq (if you are using a tweaked video mode) or use your video board utilities to set the VESA refresh rate to 60 Hz. Note that when this option is turned on, speed will NOT downgrade nicely if your system is not fast enough. -rotate No longer supported by any MAME. -nojoy don't poll joystick (not really needed with RISC OS) -log create a log of illegal memory accesses in ERROR/LOG -list display a list of currently supported games -help, -? display current mame version and copyright notice -list display a list of currently supported games -listfull display a list of game directory names + description -listroms display selected game required roms -listsamples display selected game required samples -verifyroms check selected game for missing and invalid ROMs. -verifysamples check selected game for missing samples. -romdir specify an alternate directory where to load the ROMs from (deprecated) -mouse, -nomouse enable/disable mouse support -trak enable trackerball emulation support -frameskip n skip frames to speed up the emulation. For example, if the game normally runs at 60 fps, "-frameskip 1" will make it run at 30 fps, and "-frameskip 2" at 20 fps. Use F11 to check the fps your computer is actually displaying. If the game is too slow, increase the frameskip value. Note that this setting can also affect audio quality (some games sound better, others sound worse). Maximum value for frameskip is 3. -ror rotate the display clockwise by 90 degrees. This implies '-vesa -800x600' if not specified otherwise on the command line. It also provides authentic *vertical* scanlines, given you turn your monitor to its side. CAUTION: A monitor is a complicated, high voltage electronic device. There are some monitors which were designed to be rotated. If yours is _not_ one of those, but you absolutely must turn it to its side, you do so on your own risk. ****************************************************** PLEASE DO NOT LET YOUR MONITOR WITHOUT ATTENTION IF IT IS PLUGGED IN AND TURNED TO ITS SIDE ****************************************************** -ror rotate the display clockwise by 90 degrees. -rol rotate display anticlockwise -flipx flip display horizontally -flipy flip display vertically -ror and -rol provide authentic *vertical* scanlines, given you turn your monitor to its side. -cheat Cheats like the speedup in Pac Man or the level skip in many other games are disabled by default. Use this switch to turn them on. -voices use channels for RISC OS sound. Values are: 1,2,4 and 8. -doubley use scanline doubling (useful if MAME is pickking a mode which 'letterboxes' with your monitor type - MAME will pick a larger mode but stretch the video image in the Y axis. -gappy This is only useful with -doubley. This gives 'gaps' between the doubled-up scanlines to give a more authentic effect. -hz Force only monitor definitions conforming to freqnecy. Find something else if it can't find that freqency for the given resolution. Default, or -1 is Wolverhampton female on a Friday night. -fm/-nofm (default: -nofm) on other systems, this means 'use the SoundBlaster OPL chip for music emulation in some games. This would be faster, with less faithful emulation, but we don't have soundblaster OPL. -romdir specify an alternate directory where to load the ROMs from -normalrefresh (default) -directrefresh -bankedrefresh These allow direct screen access (or bankswitched direct screen access) instead of the usual MAME blit technique (-normalrefresh), thus speeding the game up a little on slower systems. This will not work with some games, however, and banked/directrefresh are best used in conjunction with -vsync. -vg is no longer supported. It's now the default when using vector games. -antialias/-noantialias (default: -antialias) -beam n sets the width in pixels of the vectors. n is a float in the range of 1.00 through 16.00. -flicker n make the vectors flicker. n is an optional argument, a float in the range range 0.00 - 100.00 (0=none 100=maximum). -cheat Cheats like the speedup in Pac Man or the level skip in many other games are disabled by default. Use this switch to turn them on. -debug Activate the integrated debugger. During the emulation, press tilde to enter the debugger. -record nnn Record joystick input on file nnn. -playback nnn Playback joystick input from file nnn. -savecfg save the configuration into mame/cfg -ignorecfg ignore mame/cfg and start with the default settings -record Record joystick input on file INP.gamename/inp. -playback Playback joystick input from file INP.gamename/inp. -depth n (default: 16) Some games need 65k color modes to get accurate graphics. To improve speed, you can turn that off using -depth 8, which limits to the standard 256 color modes. Unless you specify otherwise, MAME will attempt to pick the correct display resolution for you given your monitor type, and choose the next nearest if that fails. Most games require 224x288. holding down CONTROL during startup will allow you to see some of the diagnostic messages giving information on what mode MAME found suitable. On a Risc PC, you can define your own modes using !MakeModes to make the best use of your monitor. The best method of setting up perfect modes for MAME are as follows: 1) Get a copy of something like !MakeModes, !CustomVDU or whatever, from any good Acorn-related FTP site (!MakeModes is available from ftp.acorn.co.uk). 2) Define a mode of either the exact size you need (eg 224x288) or one with *twice* the Y resolution so that you can use -double (and -scanlines if you like) - modes defined this way are likely to have a lower refresh rate and might perform a little better. It doesn't take an experienced modesman to define up a mode that'll work fine with your monitor type - just fiddle with a resolution reasonably close to what you're aiming for. Pass your examples of professional modesmanship to me and I'll include them with the distribution, I shall provide some ready-made monitor definition files I've defined for common monitortypes soon. To Do ===== 'Acceleration' of vector graphics.. this is something other ports don't have yet (which surprises me). -desktop operation. The TurboMAME module, which, when loaded, provides alternative 6502 and Z80 emulation for RISC OS MAME, speeding it up somewhat and making it much more usable on non StrongARM based machines. History ======= A list of doings that have been transpiring, from the beginning: [07 Jun 1997] (MAME 0.23) Started. Came in late from a nightclub. Sat down with pizza box. Got the MAME code to compile and made a start on the operating system dependant stuff. When I came to next morning, I found there was some kind of video support. [09 Jun 1997] Added keyboard support (buggy). First release made available to a few people. [11 Jun 1997] Started on the sound code. Sorted out some keyboard issues. [15 Jun 1997] (MAME 0.24.0) Notice 0.24 MAME sources are available, so grafted them in. I'll always try to ensure ARM MAME uses the absolute latest MAME source available. [22 Jun 1997] (MAME 0.24.1 extreme beta) First version with limited sound support. Limited as in it doesn't actually work very well at all. Words cannot describe how much the sound system is annoying me. I have to work with sound tables as small as 16 bytes. It's nasty. [24 Jun 1997] (MAME 0.24.1 beta 2) Sound is improved a little. Not that much, though. Certainly not enough. Damn. better screen mode selection code (well.. it's got mode selection code). This actually works well, though you're bets off defining some modes as old arcade machine resolutions are a little B'zarre. The problem with setting DIL switch options via TAB, and cycling game graphics/colours has been fixed. [26 Jun 1997] Stuff was done. Lots and lots of it. Also, I got round to doing some things too. I wondered if the things would get in the way of the stuff, but thankfully I seemed to manage both. I must have too much time on my hands or something. Anyway, the collection of things and stuff included: Scanline doubling support! Gapped scanline doubling support too. Game graphics are now centralised within the mode if the mode is larger than the games' resolution. Sound should be a lot better :-) (woohoo) Still not right though (D'oh) I wrote some documentation. It'll be the stuff you're reading right now. You lucky, lucky people. [29 Jun 1997] (0.24.1 beta 3) More work on sound, it should at least play on systems now. Let me know if it doesn't. The invaders/h problem has been worked on. All game PROMs should now be converted whether they are given names like invaders.h, invaders/h or h.invaders. Lahvly. In theory. [01 Jul 1997] Made mode selection less fussy (IE it won't give up on a resolution if it can't find it at the ideal framerate any more) Improvements to sound Williams Electronics Driver colour cycling implemented - this wasn't done before because the code to drive the DOS version directly isn't really in the right place in the MAME source (in the operating system dependant part of the code), and I was hoping it would be fixed in 0.25 but it wasn't. [02 Jul 1997] Merged in 0.25 MAME sources. Sound is better... Sorted so all the erroneous osdependant stuff hanging around in the MAME source code is worked through to my RISC OS stuff.. Because the vsync rate is so high in some monitor def files, I added the -hz option so people can force a specific frame rate for now (dropping to another mode if it can't get it) this is because constantly waiting on vsyncs which are happening all the time (when there's little backtrace time to do anything else) slows games down somewhat. The fix is really to try to define lower frame rate mdf's if you can, or define a double-height mode and use the -doubley option. [05 Jul 1997] Linked with updated C library. This at least changed the problem people were having with inability to load game files. [08 Jul 1997] Turns out the above game directory search failiure is down to a bug in either the OS, FS or library code. It's hard to find as only 3 people to my knowledge have the problem and I can't for the life of me repeat it. Anyway, let me know what this one does, as I should have worked around it. Sound is now much improved.. no, really (!)... sound streaming also supported so a *lot* more games now have sound, especially if you've picked up the .sam files to go with the ROM images. -doubley won't give up so easily finding a double Y res mode, so exceptions shouldn't happen here anymore. Overall volume setting implemented. Mouse control implementation has begun. [11 Jul 1997] (0.25.3) Linked with a completely different library. Executable should now be a few hundred K shorter and a bit faster, and I believe all the name problems have finally gone.. whopee. To get your images in order, just ensure names like pacman.6e are copied as pacman/6e - that's it. Easy, huh? All archive filings systems will do that for you as it's standard. [16 Jul 1997] Got 0.26 sources. Ported. Found 0.26 sources had problems... [17 Jul 1997] (0.26.0) Okay.. 0.26 is basically fairly shagged. The problem appears to be memory corruption within the MAME code itself (d'oh) - it's apparently with the PC version as well, so it appears I am not to blame (woohoo/d'oh). All I can say is you'll find some things work better than before, the new games supported seem to work okay, but some won't play at all at the moment. For this reason I've included the mame025 too - sorry! I'll fix it as soon as I know what is happening, but I suspect there will be a quick rerelease of MAME. Bear in mind that as I type this, only RISC OS and PC versions of MAME 0.26 exist. -nosound has been added. A bug was fixed in the sound support (some samples will no longer erroneously repeat like they were doing in MAME 0.25). [18 Jul 1997] (0.26.1) A bugfix release of MAME 0.26 (0.26a) was released and I ported this version across.. This version works, supports one or two more games than 0.26 did, and fixes colours with some games. Pacman pitch is different - note that this is due to a change in the generic MAME sources though there have been some slight sound changes by me recently. [20 Jul 1997] Tested and released. In theory any remaining keyboard problems have been sorted out. Please note that the generic source for version 0.26.1 of MAME is still not correct - this has been experienced by PC users (the only other version of MAME 0.26 right now is the PC version) - games like Pengo and Yie Ar Kung Fu are experiencing the same problem as with 0.26.0. Also, for some games, you are recommended to use the -nosound option - the generic code for 0.26 seems to be hanging at the point where it's supposed to generate wave forms to play - to get out of the hang, alt-break and then rerun mame and then exit in order to clean up the sound system. I am awaiting a newer bugfixed version of MAME 0.26 to port.. :-) [07 Aug 1997] Work on newer sound system - designed to take what I've got so far and generate a more unified SoundBlaster-style API for RISC OS. Once I've grafted this in, all remaining sound problems should be cleared up. [11 Aug 1997] (0.27.0) MAME 0.27 arrives at last :-) Ported across. There is a lot more I want to do as I have finished my other changes. Essentially I am releasing this to get any major bug problems so I can try to fix them at the same time as grafting the new sound system in. If you are having problems with hanging with some games, *RMKill MameVoices before running the emulator. -vg not implemented yet. [12 Aug 1997] -vg implemented. Vector games seem to run very nicely in 800x600 or even 1280x1024 modes. [15 Aug 1997] New Sound module! It works extremely well so sound in everything is significantly improved. The sound module is actually a very cut down version of the new sound API I'm developing, as RISC OS sound support has started to become the bottleneck for RISC OS MAME at the moment. My sound system will allow for 32 channels with mixing, Each channel can have it's own frequency, waveform, volume, and looping points. It has support for 8 and 16-bit sound systems, and optimises itself towards the system in use. The system is a sharable resource and I shall be using it myself for future projects. I shall release the API to other developers when it's further developed. Put back the Williams video driver hardware palette change optimisation which was missing from MAME 0.27.0 (I hadn't noticed they'd correctly conditionalised hardware palette availability at compile time at long last, rather than #defining MSDOS_ONLY in the Williams video hardware emulation file for hardware palettes - which is why very early versions of MAME had broken palettes for Williams stuff. Williams driver is now, as a result, back to pre-2.7.0 speeds again. [20 Aug 1997] Added additional optimisation to Williams driver (IE RISC OS is nearer the Win32 DirectX5 model, so now only one screen blit is needed, not 2 (like DOS) or 3 (like Unix). Williams drivers are now extremely fast. [21 Aug 1997] Minor tweaks to streamed sound. Mouse support is now working. This behaves in the same way as the DOS/Win32 version. Overall volume control works fully. [22 Aug 1997] (MAME 0.27.1) Trackerball emulation support added (-trak) - makes Missile Command infinately more playable :-) [25 Aug 1997] Started work on two new refresh algorithms, -directrefresh and -bankedrefresh, allowing direct screen access (or bankswitched direct screen access) instead of the usual MAME blit technique, thus speeding the game up a little on slower systems. This will not work with some games, however. [09 Sep 1997] MAME 0.28 source acquired and ported across. This includes the new MAME 68000 simulation core.. unfortunately, under ARM, this is sloooo-oooo-oooo-oooo-oooow, to say the very least. The biggest problem is that the 68000 is bigendian, and works with halfwords (as we know them in the ARM world - ie they are 16 bits).. later ARM architectures allow halfword stores (woohoo!) but IOMD(+)/7500FE does not (d'oh!). We're lucky to have an inexpensive barrel-shifter, as the emulator uses it as if it's going out of fashion. Most of the time it's taking a trip into shiftleftbytwentyfourbitsville. I found the problem with sounds with some games under RISC OS (and other versions but it only really appeared with the RISC OS version). Basically the PSG AY-3-8910 sound generator was partying on down with the memory map with the fervour of a Cwmbran Nurse. I'll reflect my changes back to the other MAME-type people, but I suspect I still have some work to do here. In fact, I definitely do, as this chip emulation is also the reason behind some games appearing to 'lock' if sound is enabled. [10 Sep 1997] (MAME 0.28.0) Tidied and released. The executable size is up by around 600K as a result of the changes made to 0.28. The inclusion of the 68000 emulator should result in an explosion of extra games supported very soon. [15 Sep 1997] Found a problem with speed throttling under RISC OS - IE it doesn't work. Basically, ARM MAME has been running too fast and without throttling until now. The problem is due to RISC OS by default not providing a timer with a greater resolution than 100 ticks a second. Correct speed throttling requires a millisecond timer which I have to implement myself when I have the time (and I'm very very busy with other projects at the moment I'm afraid...) Speed throttling is now implemented which means games run at the correct speed. To return to the speeds you're probably used to by now, turn speed throttling OFF. Actually, speed throttling won't be quite perfect until I implement a millsecond timer, the lack of accuracy in the centisecond timer means that you'll end up being just under or just over 100% speed (the little 'gaps' it fills in by waiting in order to throttle the speed can be much smaller than a centisecond). [23 Oct 1997] (MAME 0.29.0) Sorry if this one appeared relatively late (48 hour wait.. sorry ;-) ).. I'm currently up to my eyes in another project at the moment and ported this for stress relief.. Actually this one was quite complex to port due to the large numbers of changes going on at source level - there are however a lot of generic enhancements in this release. Slot size is up again I'm afraid - there's another processor (6808) being emulated too, bringing the total amount of currently emulated processors to six. Executable size is around 1600K. [31 Oct 1997] Released... [03 Nov 1997] (MAME 0.29.1) Problems fixed within MAME which now result in significant improvement of graphical quality in some games (specifically we were falling foul of the word-alignment problem with ARM loads and stores, or halfw*rds but I don't even want to begin to talk about them). Games such as StarForce, Rastan, tp84, Kangaroo etc now look far far better, and don't suffer the effect of.. well, nonaligned data loads being blitted to memory and doing all sorts of strange shimmering effects when you move, like some kind of shimmering strange effects-sort-of-thing. I've also finally got in touch with Mirko Buffoni (the MAME co-ordinator and also a very very very nice and enthusiastic bloke) to get some of the ARM version changes necessary merged into the generic MAME sources... this should save time for me in the future. A similar word-alignment problem has been fixed with the 68000 driver.. so Rastan works agaiu and at twice the speed it was before. The MAME executable has been Squeezed.. This knocks about 900K off it during storage... [10 Dec 1997] (MAME 0.29.2) Recompiled with CLib again, UnixLib seems to be causing random file opening problems with some people, probably down to something underlying in RISC OS. Damn. Correct whatsnew/txt etc files. MAME is no longer squeezed - I remembered why I didn't do it in the first place now, it adds to the size of the archive, and, as I recommend storing it in an archive anyway, it just causes an increase in space taken for most people. Some other minor bits and pieces tweaked. Placed the whole lot in a more ready-to-run directory structure. [14 Dec 1997] (MAME 0.29.3) Lots of little fixes: Implemented dirty buffering for this release. This speeds some games up (more in the future) significantly. A nasty bug in ARM GCC had stopped me being able to do this before (ARM GCC sometimes doesn't store registers on the stack with some functions, and you can end up with BL ... followed by MOV pc,r14). Dirty buffering will probably improve further in the next release. Found the problem with sound hanging with some games (eg Star Wars, Missile Command, Centipede, Asteroids Deluxe); it was the POKEY emulation doing non-word-aligned 32-bit loads and stores. Mouse positioning problems fixed. [08 Jan 1998] MAME 0.30 source finally arrives. Fixed very minor bug in pokey sound generation introduced when I cleaned it up for ARM word alignment in December. This improves sound in a few cases. -320 was setting the wrong display mode. Oops. [09 Jan 1998] (MAME 0.30.0) Tidied in preperation for release. Config loading and saving to a file will be disabled in this release until I get some more feedback from frontend authors so we can use a file format which makes everyone happy. It'll probably end up as a textual keyword file. The distribution archive now contains some cheat codes for the cheat system. Anti-Aliasing now working with the vector games. Anti-Aliasing is automatically turned on with high resolutions; you can use -noaa to turn it off. There has been a fantastic deal to do this time, I've tried a lot of games and they worked.. I could not test all of them to say the least. Please let me know of any problems. I know I have a lot to do as far as sound is concerned, this will be my next task. Executable size is around 2360K now. [10 Jan 1998] CFG/HI loading/saving mechanism fixed. Loading and saving of cheats sorted. Placed some modelists in the modelists directory... Pitch flattening problems in Galaxians etc have been fixed, also, sound streaming is improved, which should work towards the 'choppiness' you sometimes get with sounds. This is still largely dependant on your machine speed, frame skip rate configured, etc. Please note that as a result, the MameVox2 module has been upgraded - it'll all sound screwy if you use the old one. Sound streaming is not perfect yet. [11 Jan 1998] Damn. My ARM MAME page has been moved onto the restrictred resource page by Demon due to the large number of hits I'm getting for each ARM MAME release. Avtually, even the speculative hits (people checking for a newer version) are causing my bandwidth limit to be exceeded.. thus, I'll need to find a new server soon... -fm and -nofm work properly now. As this command is based on the same switch for other systems, it works oppositely to what you might expect - ie -fm actually means 'use hardware FM' - we don't have hardware FM synthesis. -nofm means use software frequency modulation synthesis, so for us, -fm means don't use have any FM synthesis at all (which is much faster), and -nofm gives us FM music etc support, but at a cost in terms of speed. [12 Jan 1998] The mame/cfg and -usecfg/-savecfg options are implemented. For front end authors, MAME creates defaults and loads and save the information to mame/cfg in the same directory as the Absolute file. The file is a standard INI format, allowing chunks and comments and so on. This behaves in more or less the same way as the DOS version of MAME. Note that the default is now to store ROMS in .ROMS, however it will try the place we're used to first, as well as trying /zip subdirectories due to image filing systems. [13 Jan 1998] Vector Anti-Aliasing setting options now saves more sensibly than the DOS version, especially if auto is set (which is the default). Auto Anti-Aliasing mode works correctly - IE it turns on Anti-Aliasing automatically for sizes greater than or equal to 640x480 resolution. Please note that, as MAME progresses, emulation of some games may appear slower; this is usually the result of something additional being emulated within that game - often sound is improved in that a whole sound processor is being emulated, or extra scroll layers are added to game which it lacked before, or the default resolution gets higher, or it was simply running too quickly before because the timings were got wrong. Please remember that in almost all cases, you are able to disable some of the extra hardware emulations added during MAME revisions, so you can revert back to old behaviour - or if you want to dabble in getting the best out of both worlds, you have options like frameskip, or screen size selectors to play with. [02 Feb 1998] General tidying, and sorting out the cheat mode hassles. [17 Feb 1998] MAME 0.30.2 This was a quick test release to prove the new streamed sound code, which should (and was) a great deal better for people. MAME 0.31 Following this point work began on the 0.31 beta series 1-17, and release candidate 1. Various updates and improvements have been effected (for example, the LED toggling for reflecting player select lamps), too many to list, and generally not dated. Huge changes have been made to the operating system dependancies in order to support MAME 0.31's various extra features - 0.31 has the greatest list of internal changes so far, covering the addition of 16 bit colour depth support, etc. The documentation has been reworked to include all of this as well, so it may be useful rescanning this whole document even if you have read it fully before. [10 Mar 1998] EmulatorUtilities module started. A timer of high enough resolution to support accurate throttling within MAME, using the hardware timer system, has been implemented first. RMLoad EmUtils before running MAME to take advantage of the new timer code. [24 Apr 1998] Release: MAME 0.31.0 Final version of the MAME 0.31 source code received from Nicola, and ported. I have very very little time to test this release with the final code. Please note that I am flying to the USA tonight (24 Apr 1998) and will be away for two weeks. Please continue to send your queries, comments, etc, to my standard address, I can still read them and reply whilst I am away, though the emulator mailing list will appear to 'pause' for the duration of my holiday. The source weighs in at 2899K. [29 May 1998] Release MAME 0.33 beta 3.1 Too many changes and things going on over the last few days to do a great deal to this readme file unfortunately, so for now please check up on latest changes and commandline/config options and differences in the generic readme files provided. Problems with configuration should be sorted now, and many changes have been made to the video system, allowing you to do sexy things like choose modes smaller than the game, and then pan the screen if you want to. Please note that the mame/cfg choices are now stored in - make sure this variable has been set up by your !Boot configuration (which it should have). Delete any existing mame/cfg files, as advised in the generic readmes. -doubley and -gappy are gone; now there is a generic name for them, use -double and -scanlines respectively. This helps to unify us with our architectural brothers and attempt to maintain a level of synchronicity in this big old world. The defaults set by MAME are nodouble (not auto or on) to maintain compatibility with what you are used to in the RISC OS world. This does mean that vector games, by default, run in a rectangle in the centre of the screen. Use -double to use the whole screen. This is correct, though I'll reconsider doubling set to auto when I can get some feedback from you regarding when we use doubling and don't, in an automatic sense. I HAVE REMOVED ZIPFILE SUPPORT FROM THIS VERSION. It's too unstable in beta 33.3. Actually, it can be activated, if you do see it working for some reason on your machine, let me know, because you could be the missing link and not know it. Also, -verifyroms can cause instability in a few cases where the ROM images are corrupt. Caution is advised, I need to speak to a few people about their respective dogs in this department. Oh, and look out for MESS :-) http://www.elecslns.demon.co.uk/MESS, and http://www.davesclassics.com for more details as and when they arrive (very soon, probably very mucharound the time you read this). Mr. Hankey's Christmas special was so brilliant, it was profound. I've thrown in some extra games which probably aren't in the DOS 0.33.3 release. This includes a whole new CPU core over 0.31 - the T11, used in paperboy. Please note that the paperboy driver is very preliminary, and I know some of the colours are inverse :-) Executable size is around 3.5 Megs. Well, look at the games and hardware it supports :-) Contrary to other versions, I will still provide end-user support for beta releases. Aren't I nice? There will be a new beta of 0.33 (4) very soon. Almost sooner than soon. Please contact me if you have any problems as per usual. [17 Jun 1998] Release: MAME 0.33 beta 6.1 This is the 0.33 beta 6 release, with some extra additions made to fix problems found with the DOS beta 6 release. Please note the changes to the way ROMs are grouped due to 'clone' games, this is mentioned in the whatsnew file. Similarly, some ROM sets now require extra colour PROM files. Various changes to the filing system code, which should work much more the way people expect it to :-) Zip file loading is now fully supported - you can use image filing systems as normal to override this. Files found which aren't directory images or normal directories will be opened as zip files. Zip Deflate or store is supported (as with the other versions of MAME). Some minor bugs in the video selection code fixed, for example, mode selection when you have a monitor definition which provides a mode of the exact size needed. I still haven't had time to properly sync this file with reality (and provide a core for my MESS documentation too) - you are advised to check what's new in the generic whatsnew and readme files, all the new DOS operations are supported. -verifyroms works fine in this release... Cheats should now work properly, I've finally nailed the compiler problems in this respect. The object code currently weighs in at 3900K, with two new CPU cores over the last release - the Signetics 2650 and Intel 8085. Next changes should involve a rewrite of the sound system to handle more than 8 voices, and 16 bit sound... [23 Jul 1998] Release: MAME 0.33 beta 7.1 This is the 0.33 beta 7 release, with some extra additions made to fix problems found with the DOS beta 6 release in the day since it was released. 628 games are supported in the RISC OS 4085K executable. ROM name selection is now case independant in the RISC OS version - IE mame PACMAN, mame Pacman etc, work, not just 'mame pacman'. When games with odd screen widths are selected, RISC OS MAME now attempts a screenmode with an even number of pixels (IE the game's width + 1) for exact mode selection, to help people generating exact sized RISC OS mode definitions. There are probably some other fixes I've forgotten about; I won't document them here yet because I've forgotten them. I will when I remember them. Please note that there are descrepancies between the command line information described at the beginning of the document and the current case; I am currently reworking the documentation for my emulators and this ifile is based on slightly older information. You should always check the generic MAME documentation anyway, this will provide you with a list of the new features which have come about in this release. This will be the last MAME version to use the MameVox2 module, in future with my emulators, there will be a separate 8 and 16-bit sound system module for you to use instead. [17 Aug 1998] Release: MAME 0.33 FINAL Note that DACSpt8 and DACSpt16 are used for this version of MAME. Currently, 16 bit support is disabled, so only the DACSpt8 module is present. Various minor fixes to the video selection code to handle the vast number of new options recently. [17 Aug 1998] Various documentation changes. There are now 10 levels of frameskip available (0-9). Frameskip value is shown within the speed indicator. The next release is likely to coincide with the optimisation drive throughout the core to benefit performance on ARM-based systems. This should hopefully significantly improve speed. Recently, floating point activity has increased within the project to the detrement of ARM-based systems, I will try to reduce the effects of this as far as I can. [18 Aug 1998] (0.34 beta 1.0) Busy, huh? ;-) Well, if you think it meant just a recompile, think again.. it takes quite a few hours to compile, for a start, and the osdependencies had some large changes too. Fixed screwy dates problem with the last entry in this readme file ;-) Use to get past the initial pages... This executable weighs in at around 4.3 megabytes. [01 Sep 1998] (0.34 beta 2.1) Various small fixes Keyboard handling improved - you can now use ENTER for game play :-) Executable size weighs in at around 4.5 megabytes. [17 Sep 1998] 0.34 beta 3.0 Slight changes to the file IO code as well as the usual OS dependency changes. Added RISC OS sprite screen save support. Unreleased due to lack of time. [16 Oct 1998] Grafting in major changes to OS dependencies [20 Oct 1998] Newer, faster screen update routines, based on 16x16 dirty grids [23 Oct 1998] file IO routines rewritten completely. Many bugs fixed. Changes made to DAC support (included frequency divisor in variable fields), module upgraded to 1.30. 'Tilde' key (left of 1) fixed for on screen display functions. [26 Oct 1998] MAME 0.34 beta 5.2 I've made a change to the way zip files are detected and treated. Previously (IE after the Friday 23 October 1998 update) directory searches for game PROMs would happen like this (we'll use pacman as an example here): 1) Check for a directory (either a normal directory or an image filing system file) 'pacman'. 2) Check for a file stamped 'data' called 'pacman' - this file would be a zip file, but as it wasn't stamped as an archive, the image filing system would not see it. If this was file found, MAME's internal zipfile routines would be used with file to extract the contents as and when needed. 3) as for 2, but for a filename with a /zip extension (pacman/zip in this case) 4) as for 1, but with a /zip extension (pacman/zip). The above two being useful for files held in a DOS partitiion or similar. It would repeat the above combinations with all your currently set paths in the ROMS, SAMPLES or whatever directories as set in mame/cfg (or *just* romdir if you use -romdir, which is deprecated anyway). *before* 23 Oct 1998, file checking was similar to the above but with some (more than one ;-) ) bugs... Anyway, the situation now is that there are few enough bugs to be able to use the native MAME zip routines as often as possible. Why? Speed in many cases - when -verifyroms does CRC32 checking on ROM image contents, where it uses it's own zipfile checking, it doesn't have to load or decompress the files to verify the checksum, because the checksum for the file is stored as a CRC32 value in the zipfile itself, which it has direct access to. It also standardises against other ports, which are now using the inbuilt routines as much as possible (overriding ZipMagic, for example). The result now will be that given the above example, if the pacman directory was an image file and not just a standard RISC OS directory, the internal zipfile routines would be used, and not the image file system's routines. Because -verifyroms checks the CRC32 value stored for the file in a zipfile, -verifyroms could report the PROM files as being correct (because the checksums match) even if the file can't be decompressed (due to disc error or internal zip corruption). In this case, manually decompressing the files into a standard directory and then running MAME is the safest bet, simply because corruption in decompressed data affects the data length more often than not, and a program loading a file through an image filing system which gives the program more data than it expected can cause it to crash. When not using the internal zipfile routines, -verifyroms is forced to read the whole file and check it's CRC32 value, which is slower. Note that if the above searching takes place within subdirectories of an image file, MAME sees these as standard directories, because technically they are - they are just directories, and not files. Sound pitch should be nearer correct - not perfect, but nearer correct than it has been over the last few releases. Hopefully I can nail it next time when I get more time - I really need bug reports from this beta, especially if you are having problems with screen update in some games (in which case sending me the error/log file from mame xxx -log would help a lot...) Note that DACSpt8 is new, and incompatible with the DACSpt8 supplied with the current test 3 of SNES9X and MESS 0.2b4. ZIP files *must* now be settype'd to Archive (DDC) for them to be treated as archives, regardless of whether you use an image filing system or not. This is how I check whether a file should be auditted as a plain file or checked as a zip file. Also, do not use non-zip-deflated files with filetype DDC for PROM directories! Damn, if only archive filetypes weren't composites of a million different *actual* formats... In fact, if you get trouble, ensure you're not making PROM directories another image filing system type (eg TBAFS archive) though there should be no need for you to want to do this.